[Framework] Add more flexible table definition mechanism #120
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This update gets rid of the HTML table templates that did not serve any useful
purpose, since the logic that goes with a table needs to be implemented in
the code one way or the other. Said differently, the code needs to know the
structure of the tables it is to generate, so hiding that structure in an HMTL
template is useless and error-prone.
The table column headers now need to appear in translation files in a `columns`
property (see `translations.json` for reference).
The types of tables and the columns to display for each of them can now be
customized on a roadmap per roadmap basis, in the `toc.json` file, in a
`tables` property that lists the columns to use per type of table. This
mechanism can be used to override the default tables or to create new types
of tables.
For instance, to add the "group" column to the columns generated in
"well-deployed" sections, one can simply add the following to the `toc.json`
file:
```json
{
"tables": {
"well-deployed": ["feature", "spec", "group", "maturity", "impl"]
}
}
```
I created a new "versions" type of column, which should eventually become what
@r12a needs in w3c#90 (not quite the case now because the framework does not
yet know how to gather the Editor's Draft and the GitHub repo of a spec)
xfq
approved these changes
Oct 29, 2017
js/generate.js
Outdated
| /** | ||
| * Code to call to generate a cell of the given type | ||
| * | ||
| * Generators should be called with an object that has the following properties: |
There was a problem hiding this comment.
Personally I'd prefer not to use the word "generator" here, because of the potential confusion with generator function, but I don't have a better name either. 🤷♂️
There was a problem hiding this comment.
I used "creator" to avoid any confusion. Not that it's much better, but that's all I could find ;)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This update gets rid of the HTML table templates that did not serve any useful purpose, since the logic that goes with a table needs to be implemented in the code one way or the other. Said differently, the code needs to know the structure of the tables it is to generate, so hiding that structure in an HMTL template is useless and error-prone.
The table column headers now need to appear in translation files in a
columnsproperty (seetranslations.jsonfor reference).The types of tables and the columns to display for each of them can now be customized on a roadmap per roadmap basis, in the
toc.jsonfile, in atablesproperty that lists the columns to use per type of table. This mechanism can be used to override the default tables or to create new types of tables.For instance, to add the "group" column to the columns generated in "well-deployed" sections, one can simply add the following to the
toc.jsonfile:{ "tables": { "well-deployed": ["feature", "spec", "group", "maturity", "impl"] } }I created a new "versions" type of column, which should eventually become what @r12a needs in #90 (not quite the case now because the framework does not yet know how to gather the Editor's Draft and the GitHub repo of a spec)
I haven't detailed that mechanism in the README for now, because it's only going to become useful when the framework supports additional column types.